A graphics hardware device is commonly used in a computer system to render two or three-dimensional representations of an object on a two-dimensional screen of a display device. Typically, an object to be rendered on the display screen is divided into a plurality of graphics primitives. The graphics primitives are basic components of a graphics picture and may be defined by the geometries of a point, line, vector, or polygon, such as a triangle. In order to render the primitives of an object, the primitives are fed through a graphics pipeline where various types of processing occurs, for example, transformation, lighting for shading, clipping, perspective division, and scan conversion. The operations of a graphics pipeline are typically performed by the graphics hardware which receives the primitive data from an application that is running on the computer system.
In the competitive market place of computer software, the time it takes for an application to render an object on a display device is a primary concern. The amount of time required is to a large degree driven by the amount of time each application interface ("API") call takes to execute. For instance, the graphics accelerators which perform their own geometry processing require that the graphics API send the application's image data directly to the graphics hardware. Further, in order to prevent multiple graphics processes from interfering with each other, a given graphics API entry point must ensure its graphics context is currently loaded in the hardware before it can initiate rendering. This checking substantially increases the overhead of the graphics API call. In high performance systems, dedicated graphics accelerators process the graphics data. Therefore, in order to achieve maximum performance, the graphics APIs must deliver the data to the graphics hardware with a minimum amount of overhead. Thus, the overhead associated with negotiating control over the graphics hardware can effectively remove the speed advantages of the graphics accelerator.
Of particular relevance are vertex based APIs wherein each component of a primitive (color, normal, texture coordinate or vertex) is specified with a separate library call, each of which requires a hardware access. Therefore, with vertex based APIs, the time required to lock (i.e., provide exclusive access) and unlock the graphics hardware amounts to a much larger percentage of the work being performed in rendering the primitive than is the case with primitive based APIs where only one library call is made per primitive. Thus, the overhead associated with locking and unlocking the graphics hardware for each component of a primitive significantly decreases the performance of vertex based APIs.
Once the API of an application has been given access to the graphics hardware, the API begins to transmit its data to the graphic hardware. The time required by the graphics hardware to process data can vary by several orders of magnitude depending upon the data and the processes being performed by the graphics accelerator. Therefore, it is possible that the data buffers of the graphics hardware may become full and that data may be lost because the graphics hardware is unable to accept further input data. Consequently, a certain amount of overhead in the graphics API is attributed to managing data flow to check that the data buffers of the graphics hardware have enough space for data that is going to be sent to the graphics hardware by an application.
Accordingly, a need exists in the industry for a system and method for accessing the graphics hardware of a computer system with no per-transaction cost. This is a particular need with regard to vertex based APIs where each library call results in a hardware access. Furthermore, it would be desirable to be able to control the flow of data from the graphics API to the graphics hardware with no device specific kernel support from the operating system, and with a minimum amount of overhead in the API so that data is not lost because the graphics hardware device is able to process the data fast enough.